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PREFACE 

This  final  report  Is  the  result  of  a two  man-month  study  to  define  a methodology  for 
structuring  the  development  of  High  Order  Language  (HOL)  code  generators  for 
special  Missile  Systems  applications.  The  report  Includes  an  analysis  of  code  genera- 
tion techniques  In  genei'al,  the  special  requirements  of  Imbedded  Missile  Systems 
applications,  and  recommendation  of  an  approach  to  pix)vldlng  effective  compilers 
compatible  with  low-cost  retargeting. 


SECTION  1 - INTRODUCTION 


I 

I 


1.1  BACKGROUND 

In  recent  years  there  have  been  two  significant  trends  in  the  DOD  community  which 
tend  to  alter  the  requirements  for  IHgher-Order  Language  (HOL)  compilers  for 
digital  computers:  (1)  The  increasing  use  of  "imbedded"  digital  computers  in 
avionics,  test  hardware,  and  other  devices,  and  (2)  The  recognition  of  the  value 
of  HOL  programming,  as  opposed  to  a machine-oriented  language  (MOL),  with 
respect  to  overall  life-cycle  costs. 

Until  fairly  recently,  the  uses  of  HOL's  were  essentially  limited  to  scientific 
research  using  large-scale  general-purpose  computers.  For  such  uses,  a com- 
piler was  both  resident  in  and  targeted  (l.e.  intended  to  generate  code)  for  the 
general-purpose  computer.  For  such  an  application,  a considerable  number  of 
man-hours  of  labor  could  be  expended  in  the  development  of  a single  compiler,  since 
they  were  not  written  that  frequently.  Since  the  compilers  were  used  in  a batch 
mode,  compiler  size  and/or  efficiency  were  sometimes  given  heavy  emphasis. 

With  the  widespread  use  of  small,  special  purpose  flight  computers  in  imbedded 
applications,  the  requirements  have  changed. 

Imbedded  computers  tend  to  be  too  small  and  specialized  to  sup)xii-t  reslde:it  HOL 
compilers.  Therefore,  the  trend  has  been  toward  the  use  of  " cToss"-compilers 
resident  on  a large,  general-purpose  computer  but  targeted  to  the  flight  computer. 

Since  imbedded  computer  applications  are  almost  always  real-time  and  often  time- 
critical,  special  emphasis  is  given  to  the  generation  of  highly  efficient  object  code. 
In  this  case,  compiler  efficiency  is  of  lesser  importance. 
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Each  digital  flight  computer  or  other  imbedded  computer  tends  to  be  highly  spt'eiall/.ed 
with  distinctive  internal  architecture  and  a unique  instruction  set.  necause  of 
technological  advances,  obsolescence  is  rapid  and  a given  computer  may  only  bo  used 
in  a single  program.  In  such  a situation,  it  is  wholly  impractical  to  develop  a com- 
plete nOL  compiler  for  each  target  machine,  oven  if  the  host  computer  is  unchar  ed. 

This  problem  has  been  compounded  by  the  advent  of  mlcivprocessors  and  the  recent 
proliferation  of  HOL's  oriented  for  missile  applications. 

A partial  solution  to  this  problem  is  to  recognize  that  many  of  the  tasks  performed  by 
a compiler  are  done  at  the  source  s>’ntax  level,  and  are  independent  of  lx>th  the  hi>st 
and  tai'got  computers  (and  even  the  HOL  being  compiled).  It  is  only  the  jwrtlon 
of  the  compiler  which  addresses  the  generation  of  actual  machine  code  that  need  Ih' 
altei'ed.  This  suggests  that  it  is  possible  to  structun'  a compiler  in  such  a way  that 
this  portion,  the  code  generator,  is  modular  and  easily  alteivd  to  adapt  to  a different 
target  computer. 

Unfortunately,  although  the  code  generator  (CG)  section  of  a compiler  is  gmierally  a 
fraction  of  the  total  code  and  raquli-es  a much  smaller  fraction  of  the  total  execution 
time,  it  tends  to  bo  the  least  structinvd  ami  orderly  iiortion.  In  this  ix'spect  it  ivflccts 
the  structure  of  the  target  machine  to  which  it  must  ultimately  conform.  Also, 
optimization  of  the  object  code  requires  Involvement  of  the  CG  in  a machine-dependent 
way. 

1.2  STUDY  OBJECTIVES 

This  study  represents  a pivliminai'y’  analysis  aimed  at  the  definition  of  a methodi'log>- 
for  structuring  the  development  of  HOT.  code  generators  for  missile  systems  applications. 
The  pui-pose  of  this  methoiiolog>’  is  to  pivvlde  a stiuetured  technique  for  providing  low- 
cost,  easlly-retargetablc  compilers  to  supjx>i't  the  software  development  for  small  missile 

applications. 
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Since  the  missile  systems  applications  of  greatest  interest  Involve  real-time  operation, 
special  emphasis  will  be  placed  upon  the  generation  of  efficient  optimized  code, 
particularly  that  for  arithmetic  expressions.  The  Intent  is  to  define  techniques 
whereby  effective  optimization  can  be  performed  without  requiring  a high  degree 
of  target  dependence  in  the  code  generator. 

The  following  ground  rules  were  adopted: 

• The  techniques  proposed  are  to  be  applicable  to  existing  compilers; 
it  must  not  be  necessary  to  develop  a new  compiler  in  order  to 
realize  some  of  the  advantages. 

• A non-optimizing  compiler  is  not  acceptable, 
o Factors  to  be  optimized  are: 

- Retargeting  cost 

- Execution  time  of  object  code,  with  emphasis  on  missile 
system  applications 

- Program  life  cycle  cost  (Impacted  by  both  size  and  time 
efficiency) 

e Factors  which  may  be  sacrificed  are: 

- Compiler  execution  time 

- Compiler  development  cost 

It  should  be  noted  that  the  factors  to  be  optimized  are,  to  some  extent,  mutually 
exclusive.  For  example,  it  is  reasonable  to  suppose  that  a compiler  designed  for 
lower  retargeting  cost  will  require  a different  organization  of  the  optimization 
algorithms,  and  thus  will  generate  somewhat  less  efficient  code. 
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The  scope  of  this  study  is  to  define  a methodology  for  structuring  the  development  of 
High  Order  Language  (HOL)  code  generators  for  special  missile  systems  applications. 
This  is  accomplished  by  an  initial  analysis  of  the  compilation  process,  followed  by 
a discussion  of  conceptual  enhancements  to  the  process  for  retargeting  which  are 
relatively  obvious  from  the  analysis. 

The  process  of  HOL  compilation  is  analysed  in  Section  2.  The  flow  from  HOL  Code  to 
machine  code  is  discussed  including  syntax  analysis,  use  of  Intermediate  languages, 
optimization,  and  code  generation. 

In  Section  3,  it  is  pointed  out  that  for  the  use  of  HOL's  in  missile  system  applications, 
it  is  not  necessary  to  redevelop  the  HOI.  compiler  for  each  new  missile  system.  The 
use  of  assembly  language  outputs  and  multiple  intermediate  languages  with  regard  to 
the  problems  of  code  generators  and  i*etargeting  is  a viable  and  economic  alteimative. 

There  are  current  tools  available  for  both  retargeting  and  I’ehosting.  The  current 
practices  and  some  of  the  tools  are  discussed  in  Section  4. 

These  discussions  lead  up  to  a set  of  conclusions  and  recommendations  pursuant  to  a 
methodology  for  code  generators  for  missile  system  applications  which  ai-e  presented 


in  Section  5. 


SECTION  2 - ANALYSIS 


2. 1 COMPILATION 

The  process  of  compilation  Is  one  In  which  an  IlOL  source  code  (consisting  of  statements 
written  in  the  sjmtax  of  the  llOL)  is  converted  into  a machine-oriented  object  code,  in 
essence,  this  process  is  one  of  string  replacement:  the  character  string  representing 
the  source  code  is  subjected  to  a series  of  transformations,  according  to  a set  of  replace- 
ment rules,  until  it  becomes  the  output  string  representing  the  object  code. 

In  general  the  direct  conversion  of  a statement  or  series  of  statements  directly  to 
object  code  is  much  too  formidable  to  attempt  in  a single  step.  Instead,  the  problem 
is  made  amenable  to  solution  by  breaking  it  doNvn  into  several  smaller  steps.  A typical 
sequence  is  symbolized  by  Fig.  2-1.  In  the  Syntax  Analyzer  (parser!  section  each 
source  language  statement  is  scanned,  the  operators  and  identifiers  are  isolated,  and 
the  statement  type  is  identified.  Incorrectly  formed  statements  are  detected  hero.  The 
source  statements  are  reformatted  to  save  space  and  tagged  with  various  Indicators 
giving,  for  example,  the  statement  tyve.  During  the  process  of  parsing,  variable  and 
subroutine  names  are  Identified  and  added  to  a symbol  table.  In  some  compilers,  the 
statements  are  reordered  to  some  extent  so  that  all  statements  of  a given  tyvo  can  be 
compiled  together.  Parsing  is  probably  the  most  time-consuming  paid  of  the  com- 
pilation process.  However,  it  can  be  made  quite  orderly.  In  fact,  automated  compiler- 
compilers  exist  which  can  generate  a parser  from  the  syntax  definitions  of  a language. 

If  global  optimization  is  to  be  performed,  it  is  done  at  this  level.  Typical  of  this 
optimization  is  the  reorganization  of  the  program  flow  to  romove  unused  or  repeated 
code,  and  to  eliminate  common  subexpressions. 
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The  structure  of  the  source  language  is  one  that  is  intended  to  be  convenient  for  the 
! user,  but  not  necessarily  for  the  computer.  In  particular,  a single  source  statement 

generally  calls  for  many  distinct  operations  to  be  performed.  Before  generating 
object  code,  it  is  first  necessary  to  Identify  these  operations  and  their  order.  To  do 
this,  it  is  common  to  define  an  Intermediate  Language  (IL)  in  which  each  separate 
operation  corresponds  to  a single  IL  instruction.  Note  that  a single  IL  operation 
may  (and  usually  does)  require  more  than  one  machine  instruction.  For  example, 
a floating  point  multiply  may  be  represented  by  a single  IL  instruction,  even  though 
it  cannot  be  directly  performed  by  hardware  and  requires  a subroutine  call  to  realize. 

The  IL  "operation"  is  chosen  to  be  any  sequence  of  Instructions  that  can  conveniently 
be  isolated  as  a self-contained,  independent  sequence.  The  language  chosen  for  the 
IL  is  still  typically  quite  abstract . Symbolic  addressing  is  used  and  little  or  no 
consideration  is  given  to  actual  machine  characteristics  such  as  word  length,  number 
of  registers,  etc. 

Following  translation  to  the  IL,  there  are  several  further  optimizations  that  can  be 
performed  at  the  IL  level.  For  the  most  part  these  are  local  optimizations. 

The  next  step  in  compilation  is  to  replace  each  IL  statement  by  an  equivalent  sequence 
of  machine-level  instructions.  This  step  is  performed  by  the  code  generator. 

Normally,  in  this  step  symbolic  addressing  is  still  retained.  In  a sense,  then,  the 
code  generator  outputs  assembly  language  for  the  target  machine.  Indeed,  in  many 
compilers,  particularly  early  ones,  this  was  the  last  step  performed.  The  assembly 
language  was  then  passed  to  a separate  assembler.  In  most  cases,  this  is  no  longei 
done.  The  reason  is  that  a separate  assembler  must  repeat  many  steps,  such  as 
building  a symbol  table,  that  have  already  been  performed  by  the  parser.  In  a 
compiler,  the  only  "assembly"  task  to  be  performed  is  that  of  assigning  specific 
I locations  to  the  symbolic  parameters.  This  task  is  perfoi-mcd  by  an  Lditor. 
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I j Between  the  CG  and  the  Editor,  a final  phase  of  global  optimization  is  performed.  The 

i i most  signification  optimization  done  here  is  that  of  register  management,  assigning 

[ parameters  to  registers  in  such  a way  that  repeated  access  to  often-used  parameters 

* can  be  done  efficiently. 

The  process  of  compilation  can  be  thought  of  as  a transformation  from  a higher  order  of 
abstraction  (HOL)  to  a low  order.  This  is  symbolized  on  an  "abstraction  continuum" 
in  Fig.  2-2.  As  indicated,  each  segment  of  the  compiler  serves  to  reduce  the  level 
of  abstraction,  which  is  finally  reduced  to  absolute  machine  code  by  the  Relocatable 
Linking  l.oader. 

The  poi*tlon  of  the  compiler  that  is  of  concem  for  retargeting  is  any  poi”tlon  which 
is  machine-dependent.  In  Fig.  2-2,  this  is  primarily  the  CG  (shaded  in  the  figure! 
but  actually  can  Include  everything  to  the  left  of  the  IT.  level.  One  observation  may  be 
: made  hero.  It  appears  that  one  reasonable  approach  to  reducing  the  cost  of  the  code 

I generator  is  to  reduce  its  resiwnsibllity  by  moving  fvinctions  either  into  the  Translator 

I or  the  Editor /.Assembler. 

I 

I 2.2  INTERMEDIATE  LANGUAGE 

The  choice  of  an  intermediate  language  for  a compiler  is  largely  arbiti-ary,  and  many  such 
languages  have  been  used.  However,  it  should  not  bo  surprising  that  the  choice  of 
Irtermcdlatc  language  can  have  a prefound  effect  on  the  compilation  efficiency,  the 
' execution  efficiency  and  the  oi'ganlz.ation  of  the  compiler  itself.  In  early  compilers,  a 

common  IL  was  Uolish  (I.ukasicwicz!  notation.  This  was  primarily  In'cause  Polish 
notation  is  easily  derived  frem  ordinary  algi'braic  notation.  Each  operator  in  Polish 
operates  on  only  one  or  two  pai'ametei's,  and  so  the  notation  meets  most  of  the 
roQUirements  for  an  11..  Unfortunately,  Polish  notation  Is  basically  a stack-oriented 
language,  whereas  all  real  cojnputers  arc  essentially  register-organized  (even  though 
they  may  support  certain  stack  operations!.  Therefore,  a considerable  anuuint  of 
translation  is  ix'qulred  in  the  code  generator  to  convert  Polish  into  machine  code. 


i 

J 

ij 

'j 

j 

i 
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Figure  2-2  Levels  of  Abstraction 


other  forms  of  IL  nro  the  tloublot,  triplet,  and  quadruple  forms.  In  those  ll.'s,  each 
IL  Instruction  consists  of  an  Instruction  operation  code,  followed  by  one,  two,  or 
throe  operands.  A typical  sequence  of  doublets  may  bo: 


LOD  X 
ADD  Y 
STO  K 
MULT  P 
SUB 
OUT 


(In  I’eallty,  of  coui*se,  numeric  operation  codes  would  be  substituted  for  the  mnemonics  shown.) 
A single  accumulator  Is  assumed  so  that  each  operation  Is  assumed  to  he  upon  the 
accumulator  and  the  named  operand.  Note  that  this  language  may.  in  fact,  be  very 
noai'ly  equivalent  to  assembly  language. 


Both  Polish  notation  and  the  doublet  form  are  best  suited  to  slngle-ai'cumulator  machine,  in 
whleh  all  operations  must  be  vxn'formed  on  the  data  in  this  accumulator  ami  the  result 
left  there.  Most  modern  computers,  however,  contain  moiv  than  t)ne  general-purix^se 
register,  at  least  some  of  which  function  as  accumulators.  For  this  reason,  most  compilers 
now  use  the  triplet  or  quadruple  form.  In  the  quadruple  form,  the  three  i>perands 
represent  the  two  painimeters  opoi*ated  upon,  and  the  source  parametei-s  which  the 
result  Is  assigned.  In  the  triplet  form,  the  source  parameter  is  omitted;  the  result 
Is  assumed  to  Ix'  left  In  the  location  assigiu'd  to  one  of  the  input  oivrands. 


In  selecting  the  form  for  the  IL,  the  architecture  of  tlx'  target  machine  s1k>u1iI  be  taken 
Into  account.  Thus,  the  doublet  form  may  be  very  efficient  for  a single-accumulator 
computer,  but  very  ixmrly  suited  for  one  with  memory  arithmetic  (that  is,  each  men.orv 
location  functions  as  an  accumulator).  For  the  latter,  a triplet  form  woulci  be  preferre.i. 
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Tailoring  the  IL  to  the  target  machine  Is  both  possible  and  desirable  for  a resident  compiler. 
It  Is  neither  for  a retargetable  cross-compiler.  This  places  even  more  emphasis  upon 
choosing  an  IL  that  is  relatively  general.  It  also  suggests  greater  Inefficiency,  at  least  in 
compile  time,  and  probably  in  object  execution  time  as  well. 

Having  selected  an  instruction  format  for  the  IL,  there  is  still  the  question  of  the  IL 
instruction  set.  This  is  a matter  of  judgement  and  experience.  There  is  no  optimum 
set,  since  the  ease  of  translation  depends  upon  the  particular  problem  being  solved. 

However,  the  IL  instruction  set  should  offer  a reasonable  correspondence  with  both  the 
operations  available  in  the  source  language  and  the  target  instruction  set.  Once  again, 
for  a multiple-target  situation,  greater  compromise  is  likely. 

2.  3 CODE  GENERATION 

Conceptually,  the  process  of  code  generation  is  very  straightforward,  and  can  be 
carried  out  by  a method  of  simple  string  substitution.  For  example,  the  IL 
quadruple 

ADD  A,  B,  C 

may  be  replaced  by  the  assembly  language  Instructions 

LOD  A 
ADD  B 
STO  C 

The  code  generator  must  simply  replace  one  string  by  another,  and  substitute  the 
operand  identifiers  in  the  proper  places,  as  indicated  by  the  underlines. 

A simple,  "quick-and-dirty"  code  generator  can,  in  fact,  be  written  in  just  such  a 
fashion.  Since  it  can  be  written  as  a table-driven  algorithm,  retargeting  would  be 
simply  a matter  of  replacing  the  tabular  data.  This  approach  is  actually  taken  when 
rapid  development  of  a new  compiler  is  required.  Since  the  CG  is  table-driven,  it  is 
relatively  easy  to  devise  automated  methods  for  developing  the  CG  itself. 
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The  difficulty  arises  when  we  also  require  efficient  object  code.  Consider,  for  example, 
the  FORTRAN  expression 

X = (A  ^ B)/C  , 

which  would  translate  to  the  IL  sequence 

ADD  A,  B,  TEMP 
DIV  TEMP,  C,  X . 

Each  quadruple  may  be  replaced  by  a set  of  three  assembly  language  Instructions 


LOD 

operation 

STO 


op  1 
op  2 
op  3 


(Here  a typical  set  of  mnemonics  for  a single-accumulator  machine  is  assumed.) 
Direct  replacement  of  the  two  quadruples  would  then  yield; 


LOD 

A 

ADD 

B 

STO 

TEMP 

LOD 

TEaiP 

DIV 

C 

STO 

X 

The  two  instructions  indicated  are  superfluous,  and  would  be  omitted  by  a human 
programmer.  Thus  a straightforw'ard  code  substitution  tends  to  load  to  very 
inefficient  code. 

It  has  often  been  said  that  a good  assembly  language  progi'ammcr  can  write  moi'c 
efficient  object  code  than  the  best  compiler,  and  this  is  in  general  quite  true.  Thciv 
are  a number  of  subtle  ways  in  which  such  a pi-egi-ammer  can  utilize  eotiing  "tricks" 
to  Improve  the  efficiency  of  his  code.  For  example,  the  optimum  method  of  imple- 
menting a given  source  statement  may  be  quite  different,  depending  upon  the  given 
problem  and  what  takes  place  in  neighboring  statements.  Such  subtlety  is  innx’ssible 
for  a simple,  substitution-oriented  CG.  It  is  the  attempt  by  the  compiler  develoix'v 
to  inject  some  of  this  subtlety  inU>  the  code  generation  process  that  results  in  a com- 
plicated, highly  machine-dependent  CG. 
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2.4  OPTIMIZATION 


From  the  discussion  so  far,  it  appears  that  the  degree  of  optimization  and  its  implementation 
has  a profound  effect  upon  the  practicality  of  achieving  the  simultaneous  goals  of  low-cost 
retargeting  and  efficient  object  code.  Therefore  the  techniques  available  for  optimization 
are  examined  next. 

2.4.1  Local  Optimization 

To  illustrate  some  of  the  techniques  for  local  optimization,  let  us  consider  the  FORTRAN 
instruction 


X = (A  ^ B)/C  - (D  ♦ E - F * G) 

Straightforward  translation  of  this  statement  yields  the  IL  sequence 


ADD 

A,  B,  TEMPI 

DIV 

TEMPI,  C,  TEMP2 

MUL 

D,  E,  TEMP2 

MUL 

F,  G.  TEMP4 

ADD 

TEMP3,  TEMP4,  TEMPS 

SUB 

TEMP2,  TEMPS,  X 

Converting  to  object  code  as  before  would  give 


LOD 

A 

ADD 

B 

STO 

TEMPI 

LOD 

TEMPI 

DIV 

C 

STO 

TEMP2 

LOD 

D 

MUL 

E 

STO 

TEMP3 

LOD 

F 

MUL 

G 

STO 

TEMP4 

LOD 

TEMP3 

ADD 

TEMPI 

STO 

TEMPS 

I,OD 

TEMP2 

SUB 

TEMPS 

STO 

X 
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This  Es  a sequence  18  instructions  long.  The  code  can  be  shortened  by  noting  that  the 


indicated  STO/LOD  pair  is  superfluous.  It  is  relatively  easy  to  design  the  CG  (or 
Editor)  to  scan  for  such  unnecessary  pairs  and  delete  them.  Although  there  are  other 
such  pairs,  they  have  different  operands  and  cannot  be  deleted.  However  If,  following 
the  deletion  of  the  first  pair,  we  exchange  the  operands  of  all  commutative  operations  (ADD 
and  MUL)  we  have 


LOD 

A 

ADD 

B 

DIV 

C 

STO 

TEMP2 

LOD 

E 

MUL 

D 

STO 

TEMP3 

LOD 

G 

MUL 

F 

STO 

TEMP41 

LOD 

TEMP4J 

ADD 

TEMPS 

STO 

TEMPS 

LOD 

TEMP2 

SUB 

TEMPS 

STO 

X 

Now  the  TEMP4  pair  (and  the  Intermediate  variable  as  well)  can  be  deleted.  Finally, 
by  permitting  the  unary  minus  operation  (the  mnemonic  CHS  is  assumed),  the 
subtract  can  also  be  reversed.  The  resulting  code  is 


LOD 

A 

ADD 

B 

* 

DIV 

C 

. 

STO 

TEMP2 

LOD 

E 

• 

MUL 

D 

. 

STO 

TEMPS 

LOD 

G 

MUL 

F 

I 

ADD 

TEMPS 

1 

SUB 

TEMP2 

CHS 

STO 

X 
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This  Is  a sequence  of  13  steps,  a reduction  of  28%  over  the  original.  An  experienced 
assembly  language  programmer  would  probably  have  written 


LOD 

D 

MUL 

E 

STO 

TEMPI 

LOD 

F 

MUL 

G 

ADD 

TEMPI 

STO 

TEMPI 

LOD 

A 

ADD 

B 

DIV 

C 

SUB 

TEMPI 

STO 

X 

which  is  only  one  Instruction  (8%)  shorter  than  the  "machine  coded"  version.  This  result 
suggests  (but  certainly  does  not  prove)  a principle  that  seems  to  hold  for  IIOL's. 

If  local  optimization  is  applied,  mathematical  assignment  statements  tend  to  compile 
very  efficiently,  and  will  run  little,  if  any,  slower  than  the  same  expression  coded  by 
band.  Since  the  great  majority  of  HOL  code  for  missile  system  applications  is 
mathematical,  there  is  reason  for  a certain  optimism  that  the  goal  of  efficient  object 
code  can  be  met  without  complex  optimization  schemes. 

It  should  be  noted  that  the  process  is  not  as  simple  as  has  been  implied.  For  example. 

If  the  term  A + B is  used  elsewhere,  then  it  would  be  incorrect  to  delete  the  STO  TEMPI 
in  the  first  pass.  The  LOD  TEMPI,  however,  can  be  deleted.  It  should  further  be 
noted  that  some  of  the  steps  outlined  here  can  be  performed  at  the  IL  level.  Thus  an 
optimizing  translator  would  have  output  the  IL  sequence 

ADD 
DIV 
MUL 
MUL 
ADD 
SUB 


A,  B,  ♦ 

♦,  C,  TEMP2 
D,  E,  TEMPS 
G,  G,  ^ 

♦,  TEMPS,  ♦ 
TEMP2,  ♦,  X 
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whore  the  astertsk  (*)  represents  the  accumulator.  The  CG  Is  still  required  rei“ORnl?.e 
the  * as  an  indication  to  skip  the  corresponding  1.00  or  STO,  and,  in  the  last  Instruction, 
to  insert  a CHS. 

Two  other  forms  of  local  optimization  are  strength  reduction  and  reduction  of  common 
subexpressions.  The  former  technique  involves  the  Identification  of  constant  subexpressions 
and  evaluation  of  them  at  TOmpile  time.  Thus 

X - (2+31-4 

would  bo  compiled  to 

LOD  1 
STO  X . 

Note  that  this  requires  the  compiler  to  evaluate,  as  well  as  compile,  arithmetic  expressions. 
In  the  case  above,  the  result  Is  obvious.  In  other  cases,  particularly  those  Involving  loop 
indices,  it  Is  much  more  subtle.  Strength  reduction  Is  most  effective  In  this  aiva  and, 
since  missile  system  appllc.atlons  tend  to  requlit?  loops  and  Indexed  variables.  Its  use 
is  highly  recommended. 

The  second  technique  Inwlves  scanning  the  source  coiie  for  common  expressions.  For 
example,  consider 

X = (A+n)^(A-P)  - (A-T>  (.\+Bl  . 

Translation  to  11.  would  yield 

ADO  A,  n,  TEMPI 

SUB  A,  B,  TEMP2 

DIV  TEMPI,  TEMP2,  TEMP3 

SUB  A,  B,  TEMPI 

Ann  A,  B.  TEMPS 

niV  TEMPI,  TEMPS,  TEMPS 

SUB  TEMPS,  TEMPS,  X 
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By  scanning  the  operator  and  first  two  operands,  we  find  the  two  operations  ADD  A,  B 

I 

and  SUB  A,  B are  performed  twice.  The  second  of  each  can  be  deleted  by  replacing  Its 
third  operand.  Thus 

ADD  A,  B.  TEMPI 

SUB  A,  B,  TEMP2 

DIV  TEMPI,  TEMP2,  TEMP3 

DIV  TEMP2,  TEMPI,  TEMP6 

SUB  TEMP3,  TEMP  6,  X 

1 Note  that  this  process  can  be  extended  globally  by  extending  the  region  of  scan.  However, 

In  this  case  the  compiler  must  verify  that  A or  B (in  this  case)  are  not  altered  between 
appearances  of  the  subexpression.  Thus  the  compiler  must  keep  a record  of  the  update 
status  of  each  variable.  Two  subexpressions  are  common  only  if  none  of  the  variables 
within  them  have  been  altered. 

In  the  case  of  loops  and  transfers,  the  status  of  a variable  at  some  point  may  depend  upon 
the  path  taken.  For  this  reason,  common  subexpressions  are  generally  scanned  only 
^thin  blocks  of  in-line  code.  In  some  cases,  this  reduces  the  potential  gains  from  the 
optimization. 

1 Note  that  both  strength  reduction  and  removal  of  common  subexpressions  are  performed 

j at  the  IL  sjmtax  level,  and  need  not  impact  the  development  of  a code  generator. 

2.4.2  Global  Optimization 
I 

There  are  many  forms  of  optimization  that  must  be  performed  globally  . . . that  is,  over 
more  than  one  source  statement.  One  example,  common  subexpression  removal,  has 
already  been  discussed.  Another  is  the  removal  of  constant  expressions  from  loops.  Note 
that  this  is  not  the  same  thing  as  strength  reduction.  An  expression  may  Involve  parameters 
1 which  are  globally  variable.  However,  if  these  variables  are  not  altered  within  a loop, 

the  expressions  can  be  moved  outside  the  loop.  Note  also  that  this  process  involves  rearrang- 
ing the  source  code,  rather  than  simply  converting  it  to  efficient  oblect  code.  This  rearrange- 
ment Is  characteristic  of  global  optimization. 
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It  should  be  noted  that  the  optimization  techniques  mentioned  so  far,  except  the 

STO/LOD  suppression,  can  also  be  performed  manually,  by  the  programmer.  This 
gives  rise  to  an  observation; 

Prior  to  the  development  of  optimizing  compilers,  the  writing  of  efficient  HOL  was  left 
to  the  programmer,  and  certain  technique  were  taught  to  achieve  this.  These  included 
avoidance  of  common  subexpressions  by  the  use  of  intermediate  variables,  precomputation  of 
constant  terms,  removal  of  constant  expressions  from  loops,  etc.  Such  techniques  were 
then  considered  good  programming  practice.  In  that  sense,  the  global  optimization  techniques 
mentioned  serve  to  correct  the  "errors"  of  the  programmer. 

On  the  other  hand,  the  current  trend  is  to  encourage  the  programmer  to  write  code  in  a 
straightforward  manner,  without  use  of  any  "tricks"  to  achieve  efficiency.  This  is  now 
left  to  the  compiler.  Thus  the  definition  of  "good  programming  practice”  has  been  changed. 
There  can  be  little  doubt  that  this  is  in  the  long-term  best  Interest  of  the  state  of  softwai'e 
development.  In  keeping  with  the  trend  away  from  machine-level  languages  and  toward 
abstract  ones,  the  programmer  should  not  be  required  to  use  certain  constructs  just  to 
satisfy  efficiency  constraints.  A program  written  in  a straightforwai'd  manner  is  more 

i 

easily  maintained  than  one  written  with  coding  tricks. 

However,  there  is  certainly  a limit  as  to  what  can  be  expected  of  an  optimizer.  It  cannot 
be  expected  to  be  lOO*!!'  efficient.  Therefore  it  seems  axiomatic  that  an  HOL  program 
1 written  to  be  efficient  will  be  more  so  than  one  written  in  sloppy  fashion  and  then  machine- 

, optimized. 

In  the  final  analysis,  the  choice,  as  usual.  Involves  a tradeoff.  WTiat  is  desired  as  a 
result  of  this  study  is  a compiler  which  can  be  easily  and  quickly  I'ctai'geted,  which  can 
generate  highly  efficient  object  code,  and  which  does  not  require  efficiency  of  coding 
by  the  programmer.  These  goals  are  to  some  extent  mutually  exclusive.  In  any  such 
tradeoff,  the  cost  of  retai*gGting  will  be  given  more  weight  here. 
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One  final  observation  can  be  made.  With  the  one  exception  of  register  management, 

* the  global  optimization  techniques  can  be  performed  at  the  source  level  and  will  not  impact 
the  development  of  the  code  generator.  Since  compile-time  efficiency  is  not  an  issue  here, 
and  since  global  optimizations  can  have  significant  impact  upon  object  execution  time,  it 

is  advisable  to  make  the  maximum  use  of  source-level,  global  optimization.  Some  enhance- 
ments to  normal  levels  of  optimization  are  discussed  in  Appendix  B, 

2.4.3  Register  Management 

The  exception  mentioned  above,  the  global  optimization  which  is  machine-dependent,  is 
that  of  register  management.  It  is  also  one  that  cannot  be  omitted,  since  it  is  one  that 
can  have  profound  effects  upon  execution  time. 

In  sin^e-accumulator  machines  such  as  were  common  in  the  early  days  of  computer 
technology,  there  was  no  management  problem,  since  there  was  no  choice  as  to  register 
storage.  This  made  the  compiler's  task  fairly  straightforward.  Current  missile  flight 
computers  typically  have  several  registers,  more  than  one  of  which  may  be  a general- 
purpose  accumulator.  In  addition,  there  may  also  be  a high-speed  cache  memory  for 
j frequently-used  data. 

The  assignment  of  global  or  temporary  variables  to  the  various  accumulators,  registers, 

‘ index  register  and  memory  tends  to  be  highly  machine  dependent.  Often  certain  operations 

t can  be  performed  in  certain  ways,  while  others  cannot.  For  example,  one  microprocessor 

‘ permits  direct  increment  or  decrement  of  memory,  but  not  add  to  memory.  It  also  permits 

a compare  of  memory  to  the  accumulator,  while  others  require  the  item  of  memory  to  be 
loaded  into  a register  first. 

Overlooking  the  machine  ideosyncracies  for  a moment,  consider  the  pix)blem  of  management 

* 

of  storage  itself.  The  first  question  to  be  asked  regarding  any  variable  is  whether  it  should 
be  stored  at  all.  This  touches  on  the  local  removal  of  STO/LOD  pairs  mentioned  earlier. 
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A variable  need  only  be  stored  if  it  is  to  be  used  later  than  the  next  operation,  or  if  it 
needs  to  be  in  a different  register  for  the  next  one.  The  process  of  determining 
variable  usage  is  called  a Dead  Variable  Analysis.  It  has  been  typically  used  for 
compressing  data  storage  in  main  memory,  but  the  same  approach  applies  to  register 
storage  as  well.  It  involves  the  building  of  a "Set/Used  Table”  which  gives  the  status 
of  each  variable.  After  the  last  usage  of  a variable,  or  the  last  usage  before  it  is  reset, 
it  is  dead,  and  another  variable  may  be  stored  in  its  place.  , 

Once  the  storage  history  of  the  variables  has  been  determined,  they  must  be  assigned  to 
storage.  For  this  purpose,  the  frequency  of  use  must  be  examined.  Variables  which 
are  used  often  should  be  stored  in  register  memory,  while  those  used  least  often  should 
be  in  main  memory.  The  t3q)e  of  usage  should  also  be  considered  For  example  loop 
counters  are  obvious  candidates  for  storage  in  index  registers.  In  the  frequency  of 
usage  analysis,  the  program  should  be  considered  in  blocks.  It  may  be  useful  to 
provide  both  register  and  main  memory  storage  for  a variable.  For  example,  it  may 
have  a high  frequency  of  usage  within  a loop.  In  such  a case  it  would  be  convenient  to 
move  the  variable  to  a register  before  beginning  the  loop,  and  move  it  back  to  main 
memory  upon  loop  exit.  Obviously,  the  compiler  must  provide  for  proper  update  of 
memory  for  all  possible  exit  paths  from  the  loop. 

While,  as  mentioned,  the  optimum  assignment  of  storage  can  be  highly  machine 
dependent,  it  appears  that  the  dead  variable  analysis  can  at  least  be  partially  mechanized  in 
a regular,  parameterized  fashion,  i.e.  fora  machine  with  n accumulators,  m registers, 
k index  registers,  etc.  There  will  probably  remain  a certain  amount  of  register  assignment 
that  must  be  handled  differently  for  each  target  machine.  One  (non-optimal)  way  to  handle 
this  is  to  assign  specific  registers  for  certain  special  tasks  (e.g.  index  4 for  subroutine  offsets, 
index  1 for  loops). 
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SECTION  3 - ENHANCEMENTS  FOR  RETARGETING 


In  the  situation  of  interest  in  this  study.  It  is  assumed  that  it  is  not  necessary  to  develop 
a complete  new  compiler.  Rather,  It  is  assumed  that  an  IlOL  compiler  exists  and 
is  resident  on  the  host  machine,  and  it  can  be  modified  to  meet  the  goal  of  low-cost 
retargeting.  Some  modifications  and  enhancements  capable  of  reaching  this  goal 
are  discussed  in  this  section. 


r 


3.1  ASSEMBLER  LANGUAGE  OUTPUT 

Recall  that  in  Fig.  2-2,  all  portions  of  the  compiler  to  the  left  of  the  IL  level  are  (or  may  be) 
target  machine-dependent.  If  the  code  generator  outputs  to  an  editor  rather  than  an 
assembler,  this  editor  is  target- depen  dent  and  the  cost  of  retargeting  the  editor  must  be 
considered  along  with  that  of  the  CG.  A similar  statement  holds  for  the  linking  loader. 

If  retargeting  of  the  editor  and  loader  can  be  removed  from  consideration,  the  cost  of 
retargeting  can  obviously  be  cut.  This  is  possible  if  a stand-alone  cross-assembler  and 
loader  can  be  assumed  to  be  available  for  each  potential  target  machine.  This  is  a 
reasonable  assumption.  All  manufacturers  of  commercial  computers  and  micro-processors 
offer  cross-assemblers  with  macro  capabilities.  Most  arc  written  in  FORTRAN  IV  for 
portability.  There  is  a charge  for  those  assemblers  of  about  $500  - $2500,  but  this  is 
small  compared  to  the  cost  of  retargeting  the  editor.  The  only  case  in  which  a 
cross-assembler  is  not  likely  to  be  available  is  for  a bit-slice,  micix)progi'ammed  machine 
with  a custom  instruction  set,  for  which  no  assembler  has  been  written.  Tliis  is  an 
unlikely  oocurencc.  In  any  case.  If  a computer  with  a non-standard  instruction  set  is 
selected,  the  cost  of  developing  an  assembler  slwuld  really  be  charged  to  the  hardware 
development  effort,  rather  than  to  software. 

One  consideration  should  be  borne  in  mind.  Although  cross-asseniblers  atx'  generally 
available  for  the  computers  of  interest,  they  are  not  uniformly  ixnverful.  They  tend  to 
have  rather  limited  macro  facilities  and  limited  diagnostics.  Since,  however,  tlio 
input  to  the  assemblers  will  lx?  machlne-gi'nerated,  this  is  not  seen  as  a problem. 
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3.2  MULTIPLE  11/ S 


As  montlonoil  In  Soctlon  2.2,  the  typical  compllor  IL  is  quite  ahatnict.  AlthouRh  It  tloea 
have  one  Inatnictlon  for  each  dlatlnct  operation,  the  Instructions  and  format  do  not 
corn'8ix)nd  to  any  jwtontlal  target  machine.  TIh'  ad«li'i>s8lng  Is  symlxillc,  and  no  rt'ganl 
is  given  to  actual  machine  considerations  such  ns  word  length,  storage  format,  jx'glster 
available,  etc.  To  ik>  so  would  Inject  machine  ik'i>endencles  Into  the  translator  section 
of  the  compiler,  which  Is  clearly  undesirable.  However,  the  degn'e  of  abstraction 
associated  with  tyi>leal  ILLs  places  a givater  load  on  tin'  task  of  code  gi'neratlon  than  Is 
necessary. 

Referring  to  KIg.  2-2,  supiwse  that  the  code  gi'nerator  could  be  split  Into  two  pails,  one 
of  which  Is  machine-dependent,  the  other  of  which  Is  not.  Then  only  th<'  second  ix»i1lon 
need  be  Involved  In  ivtargetlng.  dno  way  of  doing  this  Is  to  define  a secoml  IL,  less 
absti'act  than  tlx'  llrst,  ami  one  more  closely  akin  to  mai'hine  languagi'.  The  situation  Is 
symliolt/.ed  In  V'lg.  2-1 . 

In  effect,  this  appivai'h  is  equivalent  to  tleflnlng  a fictitious  computer,  an  "abstract  machine" 
which.  If  mechanized,  would  dlivctly  execute  the  lnsti'ucth>ns  of  the  sci'ond  IL.  'Phis  con- 
cept of  an  nbsti-.U't  machine  Is  well  established  In  the  literatim'  (11,  (21,  (21,  (-ll.  Tlu' 
ordlnai’y  IL  of  any  compiler  may  be  ivg'anled  as  the  two-or  thn'<' -address  machliu' 
language  for  an  abstract  machine.  In  fact,  any  langaiagv,  IncUullng  the  original  UOL,  may 
lx>  ns.soclated  with  an  abstract  machine.  neiH'iidlng  «{x»n  lh<'  nu'th»>d  of  implementation, 
the  tool  for  conversion  fi'om  the  abstract  machine  language  to  llu'  target  languagi'  may  be 
ix>ferred  lo  as  an  emulator,  inteniretcr  or,  as  In  thi'  curri'iit  cast',  !i  cod«'  gi'iu'nitor.  Tlu* 
I’oncept  of  multiple  IL's  has  ivcently  rocelveil  consldi'rabb'  atti'iitlon  In  tlu'  development  ol 
lnlen'>'»'tlve  languages  for  mlcro|m>cessors  (HI,  (71,  (.*<). 

V'or  the  puiixises  of  the  current  sluil>’.  It  Is  suggi'sted  that  tlu'  second  IL  taki*  the  lorm  of 
a "Unlvei'sal  Assemblei'",  language  whose  Instnictlons  aiv  at  the  machine  operation 
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level,  but  do  not  necessarily  correspond  to  any  actual  machine.  Such  a language,  called 
"MIMIC",  Is  actually  In  use  In  CSC  software  development  activities.  For  the  selection  of 
the  universal  assembler  (UA)  language  It  Is  necessary  to  define  an  "Ideal  Machine",  with  an 
Instruction  set  that  represents  a rational  set  of  machine-level  Instructions,  leading  to 
efficient  "object"  code  (note  that  all  real  computers  should  be,  but  rarely  are,  designed 
In  this  manner).  The  code  generator  task  then  becomes  a simple  macro  substitution  of 
target  machine  Instructions  for  the  UA  "pseudo-ops". 

For  this  approach  to  result  in  reasonably  efficient  object  code,  the  instruction  set  for 
the  UA  must  be  carefully  selected.  For  example,  the  instruction  set  for  the  UDP-11 , 
like  many  IL's,  Is  basically  two-address.  If  the  UA  were  chosen  to  correspond  to  a 
single-address  ideal  machine,  the  resulting  code  may  tend  to  be  inefficient,  it  is 
difficult  to  imagine  a single  U.A  which  pix>vides  a good  match  to  all  compute i*s.  Fortunately, 
It  Is  only  necessary  to  generate  efficient  object  code  for  a special  subset:  those  computers 
which  are  candidates  for  missile  flight  systems.  It  is  suggested  that  the  instruction  sets 
of  these  candidates  be  examined  in  oi-der  to  synthesize  the  U.A  instructions.  Within  DOD 
an  effort  Is  underway  to  define  a standard  instruction  set  for  all  futinv  DOD  applications. 

The  Instruction  set  for  this  "Software  Compatible  Family"  is  an  obvious  choice  for  the  U.A. 

Although  the  UA,  and  the  first  code  generator  which  translates  to  it,  is  intended  to  be 
machine-independent,  there  are  some  cases  in  which  this  should  not  be  strictly  enforced. 

For  example,  if  the  target  machine  is  a IG-blt  machine,  then  the  U.A  should  also  be,  to 
avoid  extensive  data  translation  requii*ements.  It  apivars  that  such  considerations  can 
bo  treated  parametrically,  by  storing  the  machinc-dciH?ndcnt  parameters  in  an  easily 
altered  table.  Machine  dependence  of  this  parametric  type  need  not  Ih'  feaivd,  and  is 
consistent  with  a parametric  approach  to  optimization. 
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SECTION  4 - CURRENT  PRACTICE 


An  example  of  the  current  practice  in  compiler  development  may  serve  to  suggest  some 
parallel  approaches  for  the  current  needs.  Such  an  example  is  provided  by  CSC's 
development  of  the  J-3B  and  J-73  compilers  for  the  Air  Force.  These  compilers  were 
developed  speclficall5'  for  dedicated  avionics  applications,  and  feature: 
o High  level  of  optimization 
o Heavy  use  of  compiler  development  tools 

o Developed  directly  from  source  language  ssratax  specifications 
o Well-defined  IL  and  CG  interfaces 
o Designed  for  efficient  rehosting  and  retargeting. 

Some  tools  associated  with  these  compilers  and  their  development  are  discussed  next. 

4. 1 SYMPL 

Systems  Programming  Language  (SYMPL)  is  a CSC  - proprietary  programming  language 
developed  using  systems  programming  aspects  of  FORTRAN  and  PL/1.  It  has  been  in  use 
for  over  13  years  in  the  development  of  compilers.  The  production  versions  of  CSC  - 
developed  compilers  are  often  written  in  SYMPL,  which  are  then  compiled  into  object 
code. 

4. 2 GENESIS 

This  CSC  - proprietary  language  is  a compiler  development  tool,  useful  for  compilers 
which  can  be  written  in  a table-oriented  form.  Based  upon  the  defining  syntax  specifica- 
tions for  the  language,  GENESIS  generates  the  tables  and  connecting  software  which 
serve  to  Implement  the  syntax  analyzer  section  of  the  compiler.  The  output  of  GENESIS 
is  SYMPL  source  code. 
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4.3  JOCIT 

For  the  automated  development  of  J-73,  the  JOCIT  program  was  developed.  This  program 
Is  both  a JOVIAL  compiler  and  a compiler-compiler.  A complete  description  of  JOCIT 
and  the  requirements  for  retargeting  it  are  given  in  Appendix  A.  Some  optimization 
enhancements  to  JOCIT  are  discussed  in  Appendix  B. 

4.4  ACG 

The  Automated  Code  Generator  (ACG)  is  a CSC -proprietary  program  developed  to  achieve 
rapid  retargeting  for  JOVIAL  compilers.  The  program  is  designed  to  aid  in  the  development 
of  quick-response  code  generators  of  a table-oriented  nature.  The  resulting  "Quick  code" 
generators  are  typically  used  as  interim  generators  until  more  efficient  retargeting  can  be 
effected. 

4.5  AUTOMATED  TOOLS 

As  can  be  seen  from  the  descriptions  just  given,  the  current  state  of  the  ai-t  involves  the 
extensive  use  of  automated  software  tools  to  develop  other  software.  With  the  aid  of  these 
tools,  it  is  perfectly  feasible  to  fully  develop  a compiler  from  its  sjmtax  definition,  without 
ever  working  in  the  assembler  language  of  the  host  machine.  This  approach  is  clearly  in 
keeping  with  the  recognized  advantages  of  HOL  programming. 

i 
i 
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SECTION  5 - CONCLUSIONS  AND  RECOM MENDATIONS 


On  the  basis  of  the  analyses  presented  in  this  report,  it  appears  that  it  Is  feasible  to 
modify  an  existing  HOL  to  provide  low-cost  retargeting,  without  severely  degrading 
the  object-time  execution  efficiency.  Some  specific  recommendations  have  been 
identifled  and  are  summarized  below.  ' ' ^ 

5.1  COMPILER  ORGANIZATION 

The  compiler  chosen  must  have  an  architecture  such  that  there  is  both  a well-defined 
intermediate  language  (IL)  and  a modular  code  generator  (CG).  An  IL  composed  of 
triplets  or  quadruples  is  preferred,"  That  portion  of  the  compiler  not  included  in  the 
CG  or  Editor  must  not  be  target  dependent. 

5.2  OPTINRZATION 

The  compiler  chosen  must  have  extensive  capability  to  perform  global  optimization.  It 
is  suggested  that  existing  capabilities  be  enhanced  to  include  code  sti-aightoning,  dead 
variable  analysis,  and  loop  optimizations.  The  Impoi-tant  area  of  register  management 
should  be  performed  in  a parametric  manner,  so  that  retargeting  can  be  accomplished 
by  loading  a table  of  machine  parameters; 

5.3  ASSEMBLY  LANGUAGE  OUTPUT 

The  code  generator  should  output  a character  string  consisting  of  assembly  language 
for  the  target  machine.'  Assembly  and  linking  shall  be  accomplished  off-line  by  separate 
software. 

5.4  MULTIPLE  IL’S 

At  least  one  extra  level  of  IL  should  be  considered.  This  should  consist  of  a universal 
assembler  (UA)  language  whose  instructions  represent  assembly  language  instrections 
for  a fictitious,  "ideal  machine."  In  the  selection  of  this  language,  it  is  suggested  that 
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candidate  missile  system  computers,  particularly  the  "Software-Compatible  Family", 

1 

• be  examined.  Machine  dependencies  such  as  word  length  and  number  of  registers 

should  be  parametric. 

5.5  AUTOMATED  TOOLS 

! It  is  suggested  that  all  automated  software  tools  available  such  as  compiler-compilers  be 

used.  The  availability  of  such  tools  should  be  a factor  in  the  choice  of  the  base  HOL 

i 

I i compiler.  j 
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APPENDIX  A 


JOCIT 


A.l  BACKGROUND 

The  original  Intent  of  the  JOCIT  effort  was  to  develop  a compiler  building  tool  for  the 
J73  language.  When  the  J73  contract  was  awarded,  the  language  still  was  not  firmly 
defined,  and  after  a few  weeks  of  study  of  the  language  it  was  determined  that  the 
development  costs  were  higher  than  originally  estimated.  Therefore,  in  order  to 
produce  a more  useful  product  that  demonstrated  the  principal  elements  of  the  original 
objectives,  the  project  was  redirected  towards  developing  a J-3  compiler  building  tool. 
Since  the  need  within  the  Government  for  a J-3  capability  was  sufficiently  real  and  urgent, 
the  new  project  goals  were  highly  practical.  The  principal  objectives  of  the  JOCIT  J-3 
development  were  to: 

• Reduce  the  time  and  cost  of  implementing  and  maintaining 
JOVIAL  J-3  compilers 

• Ensure  that  JOVIAL  language  sets  implemented  on  different 
computers  are  consistent 

• Enable  the  rapid  inclusion  of  any  new  JOVIAL  features  into 
every  compiler  built  with  the  tool,  including  those  compilers 
Implemented  before  the  feature  was  accepted 

• Enable  the  compilers  built  with  the  tool  to  incorporate  modern 
optimization  techniques  that  overcome  many  forms  of  poor 
programming 

Although  the  redirection  to  produce  a running,  debugged,  efficient,  and  reliable 
J-3  compiler  necessarily  had  the  effect  of  diluting  some  of  the  goals  of  the  tool. 
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nevertheless,  the  objectives  were  largely  met.  The  most  objectively  measurable 
result  of  the  JOCIT  effort  was  the  development  of  a production-grade  J-3  compiler 
currently  in  heavy  operational  use.  However,  it  is  somewhat  difficult  to  assess  the 
result  of  the  tool  development  in  equally  objective  terms,  because  no  new  retargeting 
or  rehosting  effort  has  been  undertaken.  The  following  paragraphs  describe  the  essential 
features  of  the  JOCIT  program  and  assess  the  relative  success  in  meeting  the  stated  goals. 

A. 2 DESIGN  FEATURES  i 


The  following  design  elements  were  incorporated  into  JOCIT: 

• Target-machine-dependent  code  isolated  into  functional  modules 

e Global  optimization  techniques  to  meet  the  requirements  of  language 
independence,  host-machine  independence,  and  target-machine 
independence 

e The  GENESIS  system  used  for  writing  the  J-3  language  specifica- 
tion, the  resulting  tabular  form  of  which  is  processed  by  a 
language-independent  analyzer  program 

• A prototype  compiler  to  compile  the  full  J-3  language;  the  prototj’pe 
can  be  used  as  a model  for  rehosting  the  J-3  version  or  as  a basis 
for  building  a J73  JOCIT 

• Over  95  percent  of  the  JOCIT  code  written  in  an  llOL  (SYMPL); 
use  of  machine  code  is  restricted  to  host-machinc-dependent 
Interfaces 

A.  3 CHARACTERISTICS  OF  THE  JOCIT  J-3  COMPILER 

JOCIT  embodies  the  following  three  features  which,  together,  I'calize  the  goal  of 
a tool  for  the  generation  of  standard  JOVIAL  J-3  compilers: 

• JOCIT  is  a stable,  well-debugged,  efficient,  production-quality 
J-3  compiler.  It  realizes  the  most  advanced  optimization  in  any 
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JOVIAL  J-3  compiler  to  date,  and  even  though  the  compiler  ia 
large  (40-50K  words  of  HIS-GOOO  main  memory),  It  Is  quite  fast 
and  generates  exti'emely  informative  and  useful  listings. 

• Retargeting  of  JOCIT  is  a known,  relatively  straightforward,  but 
not  trivial  process.  It  Is  achieved  thix)ugh  total  replacement  or 
partial  modification  of  certain  compiler  modules,  and  the  installa- 
tion of  the  JOVIAL  library  on  the  new  target  machine. 

• Rehostabllity  of  JOCIT  Is  achieved  principally  by  progi'amming  the 
JOCIT  modules  in  SYMPL.  Rehosting  is  considerably  more  com- 
plex than  retargeting,  but  the  steps  are  well  understood  and  meet 
the  tool  requirement  by  costing  only  a fraction  of  a comparable, 
totally  new  compiler  implementation. 

These  three  considerations  are  addr*essed  in  the  following  subsections. 

A.  3.1  USER  INTERFACE 

The  JOCIT  J-3  compiler  is  operated  in  a standard  fashion  entirely  compatible 
with  other  GCOS  language  precessore.  Th.at  is,  the  command  syntax  and  file 
specifications  conform  to  GCOS  standarxis,  and  the  JOCIT  user  is  required  to 
leanr  only  the  computer  options  in  order  to  invoke  tlie  compiler. 

A. 3. 2 THE  J-3  LANGUAGE 

JOCIT  implements  the  full  J-3  language,  with  certain  extensions  added  to  satisfy 
unique  customer  requirements  (including  a special  source  language  I O facility 
to  satisfy  a user  requirement  for  compatibility  with  the  nonstandard  llone\'well 
J-3  compiler).  The  diagnostic  cav>abillty  is  tlwireugh,  and  extensive  use  is  made 
of  parameterized  diagnostics  (for  example,  providing  for  insertion  of  identifier 
or  reseiwed  word  names). 

A. 3. 3 COMPILER  LISTINGS 

The  JOCIT  eompiler  proviik'S  a comprehensive  set  of  compiler  listings.  These 
listings  Include  interspersed  Phase  I diagnostics;  a consistent  diagnostic  format 
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for  all  phases;  an  extensive  object  program  assembly  language-format  listing 
identical  to  GMAP,  a complete  "set-used”  listing  for  all  program  constructs 
(define  names,  status  constants,  program  variables,  labels,  procedures,  etc.); 
and  a program  environment  listing. 

A. 3. 4 OBJECT  PROGRAM  EFFICIENCY 

The  JOCIT  program  expends  much  effoi't  to  obtain  object  program  efficiency. 
This  has  been  achieved  through  two  means:  global,  target-machine-independent 
optimization,  and  a code  generation  scheme  that  optimizes  register  usage  and 
performs  considerable  special  case  analyses.  Global  optimization  includes: 

• Elimination  of  redundant  common  expressions  computations 

• Redistribution  of  loop-constant  code 

• Reduction  of  formal  loop  operator  strength 

• Improvement  of  compile-time  constant  arithmetic  and  subexpivss- 
lons  (e.g. , elimination  of  multiplications  by  1) 

• Recognition  of  dead  code 

• Evaluation  of  compile-time  const.ant  predicates 
(e.g.,  AA  1$...1FAA$) 

All  computational  memory  is  en)lx>died  in  the  optimizer-code  generator  file  (ID 
Interface,  while  local  o;4imiz:Uions  are  perfonned  by  the  code  gimerator  to  pix>- 
ducc  the  optimum  sequence  for  each  recognizable  case.  The  combination  of 
global  and  local  oi>timization,  which  attempts  to  minimize  generated  code  space, 
successfully  realized  in  the  JOCIT  J-3  compiler.  Fuilher  impix^vements  that 
would  have  a higli  paroff  in  production  progi*ams  aiv: 

• Regional  index  ivgister  dedication 

• l,oop  control  vari.able  <1A'V)  imk'x  register  dedication 

• Improved  strength  n'liuction.  Including  test  tx'placemcnt  and  deaii 
1,CV  elimination 
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• Dead  variable  analysis 


• Code  straightening 

Of  the  60  percent  improvement  in  generated  code  over  the  previous  HIS  J-3  com- 
piler, 10  to  15  percent  is  attributable  to  global  optimization,  while  the  balance  is 
derived  from  the  local  code  generation  algorithms.  Even  though  there  is  room 
for  improvement,  the  level  and  quality  of  the  realized  optimization  are  the 
notable  achievements  of  the  JOCIT  J-3  model. 

A. 3. 5 COMPILER  EFFICIENCY 

Considering  its  optimizing  capabilities,  the  JOCIT  J-3  compiler  is  comparatively 
fast.  However,  the  compiler's  instantaneous  main  memory  requirements  are 
quite  high;  40K  words  is  the  minimum  partition  plus  the  size  required  for  the 
compiled  program’s  symbol  table.  The  compiler  already  is  heavily  segmented 
into  separate  overlay  loads.  Only  a radical  redesign  could  reduce  the  core 
requirements,  and  only  at  the  cost  of  severely  reduced  compiler  speeds.  The 
large  size  of  the  compiler  is  due  to  the  following  reasons  (listed  in  descending 

order  of  impact): 

• Complexity  - The  JOCIT  J-3  compiler  was  designed  for  maximum 
user  utility.  It  performs  an  enormous  number  of  complicated 
tasks  in  order  to  produce  pinpoint  diagnostics,  to  perform  global 
flow  analysis /optimization,  to  pack  tables  optimally,  and  to  pro- 
vide a sophisticated  and  useful  COMPOOL  facility.  The  augmented 
J-3  language  it  compiles  is  huge,  and  the  code  generator  achieves 
its  goals  through  complex  algorithms  that  require  a considerable 
number  of  source  code  lines  to  effect.  It  is  doubtful  that  the  num- 
ber of  lines  of  code  in  the  compiler  itself  could  be  materially 
reduced  without  seriously  compromising  user  convenience  and 
object  code  performance. 
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• Compiler  Architecture  - The  compiler  uses  a minimum  number  of 
phases  and  intermediate  files  and  requires  a large  symbol  table  to 
be  resident  throughout  the  compilation  process.  It  is  conceivable 
that  by  partitioning  the  compiler  into  more  functional  phases  (a 
multipass  code  generator  is  a possibility)  the  maximum  phase  size 
could  be  reduced;  but,  as  pointed  out  earlier,  compiler  speed 
would  be  reduced  and  additional  program  complexity  (more  inter- 
mediate files,  for  example)  would  result. 

• Use  of  HOL  - Because  of  the  JOCIT  J-3  compiler  is  written  in  SYMPL 
and  compiled  by  a small  compiler  which  incorporates  only  a modest 
number  of  local  optimizing  algorithms,  the  JOCIT  compiler  con- 
tains more  lines  of  object  code  than  would  be  the  case  if  it  had  been 
written  in  assembly  code  or  compiled  by  a sophisticated,  optimiz- 
ing SYMPL  compiler.  A more  compact  compiler  also  could  be 
achieved  by  rewriting  the  JOCIT  compiler  using  J-3,  thereby 
obtaining  the  benefits  of  the  compiler's  own  optimization.  How- 
ever, the  J-3  language  is  much  less  suited  to  compiler  implemen- 
tation than  is  SYMPL  and  carries  excess  baggage  (e.g. , fixed 

point  arithmetic,  lengthy  prologues  and  epilogues)  that  is  costly 
and  unnecessary.  Optimizations  could  be  added  to  the  SYMPL 
compiler  to  reduce  object  code  without  unduly  compivmising 
rehostability  or  retargetability  of  cither  SYMPL  or  JOVIAL. 

A.  3.  6 DEBUGGING  (USER) 

The  inclusion  of  the  MONITOR  statement  and  ENCODE/DEC'ODE  pi-ovide  consid- 
erable debugging  convenience  for  the  user.  In  particular,  the  availability  of  the 
compiler  command  option  to  suppress  compilation  of  all  MONITOR  statements 
allows  the  user  the  convenience  of  retaining  his  MONITOR  statements  in  the 
source  program  without  paying  the  compilation  - and  resulting  object 
program  - price. 
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A. 3. 7 DEBUGGING  (COMPILER  MAINTENANCE) 


Tho  JOCIT  model  includes  a wide  range  of  built-in  compiler  debugging  features, 
mostly  in  the  form  of  formatted  table  and  file  dumps  that  can  be  selected  indi- 
vidually during  maintenance-mode  execution  of  the  compiler.  The  debugging  rou- 
tines themselves  occupy  symbol  table  space  and  are  overwritten  by  symbol  table 
entries  during  production-mode  compilation.  Thus,  the  production  mode  com- 
piler is  not  enlarged  since  tho  maintenance  debugging  routines  are  not  ordinarily 
present;  however,  full  debugging  capability  is  available  in  the  eompiler  by  exer- 
cising an  option. 

A.  3.  8 RELIABILITY 

The  reported  error  rate  on  the  production  JOCIT  J-3  compiler  is  comparatively 
low.  The  errors  tend  to  be  distributed  throughout  tho  compiler  modules,  and  it  is 
rare  for  tho  compiler  to  fail  completely.  Not  surprisingly,  the  most  vulnerable 
phase  of  tho  compiler  is  the  optimizer  since  very  large  pi-ograms  with  complex 
flow  can  cause  the  optimizer  to  abort.  However,  in  keeping  with  tho  diagnostic 
approach  of  the  design,  these  failures  are  (almost  without  exception)  self- 
detected  anomalies.  Most  optimizer  failui'cs  relate  to  unnecessarily  complex 
space  management  functions  which  are  subject  to  unpredictable,  subtly- 
compounded  errors.  The  forthcoming  JOCIT  improvements  project,  which 
provides  for  considerable  optimization  enhancement,  will  include  simplified 
restructuring  of  the  optimizer  data  base  and  space  manager  to  stn'ngthen  this 
area  considerably. 

A. 4 RETARGETING 

In  order  to  achieve  retargeting  of  the  present  JOCIT  model,  llic  following  steps 
arc  roquired: 

!•  Develop  library  for  target  machine. 

2.  Adjust  eompiler  cock'  for  target  machine  sensitivity. 

3.  Write  new  direct  code  pi'occssor. 
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I 4.  Write  new  code  generator. 

5.  Modify  the  editor  phase  to  produce  object  code  listing  in  new 
target-machine  format. 

I 6.  Add  new  object  module  formatter. 

7.  Provide  for  translation  of  host-machine  constant  formats  to 
target-machine  formats. 

j These  steps  are  discussed  in  detail  in  the  following  paragraphs. 

A. 4.1  LIBRARY  INSTALLATION 

I The  J-3  library  consists  mainly  of  I/O  and  ENCODE/DECODE  routines,  string 

routines,  and  MONITOR  routines.  Retargeting  requires  rewriting  these  routines 
j for  each  new  target.  Except  for  the  MONITOR  routines  written  in  SYMI’L,  these 

routines  are  written  in  assembly  code  that  Is  not  directly  transferable  to  a new 
target  machine.  Installation  of  the  library  is  not  a simple  task  since  even  the 
MONITOR  routines  must  be  rewritten  (unless,  of  course,  a SYMPL  compiler 
j exists  for  the  new  target  macliine). 

j A. 4. 2 ADJUSTMENT  FOR  TARGET-MACinNE  SENSITIVITY 

Many  routines  within  the  compiler  are  affected  by  various  chai'acteristics  of  the 
j target  machine.  These  are  partly  parameterized  through  use  of  a target-machine 

descriptor  block.  However,  this  parameterization  is  not  yet  complete.  Typical 

T 

parameters  of  interest  are; 

* 

• Target  word  size 

• • Target  byte  size  (bits  per  byte) 

’ o Target  bytes  IK!  r wo  I’d 

‘ • Maximum  and  minimum  integer  values 

J o Maximum  .and  minimum  floating  values 

‘ • Medium  packing  access  field  descriptions 

I • Addressing  imits  per  woi’d 


• Character  set  Internal  representation 
o Target  numeric-value  representations 


The  following  routines  within  the  compiler  presently  must  be  adjusted  as  described 
below; 
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ALOCTR 

XREF 

CCP 

JXEC 

CO  MOST 

PC  ON 

JINIT 

JPFl 

PFIPIU 

OPT2A 


Object  Program  Data  Allocator  - Describe  medium 
packing  and  typo  characteristics. 

Cross-Refci-ence  Lister  - Tailor  target-dcfKmdent 
listing. 

Compiler  Control  Program,  i.c. , conti\)l  card 
scanner  - Recognize  multiple  target  option. 

Compiler  Executive  or  "cradle"  - Sequence  the  com- 
piler as  necessai7  for  different  target-dependent  phases 
(e.g. , the  code  gencratorL 

Target  Pai’ametcr  Data  Plock  - Modify  target-machine 
parameters. 

Constant  Posting  Routine  - Modify  as  necessary  to  reflect 
different  intenial  forms  for  target. 

Initialization  of  Compiler  - Post  target -specific  intrinsic 
functions,  if  any  (for  example,  the  correct  library  nmline 
entry  point  name  for  the  string  routines.  1 'O  routines, 

etc. ). 

Pass  1 Analysis  Pragmatic  Functions  - t'onvert  source 
form  constants  to  target  form. 

Preset  Processing  Subrovitlne  of  Pass  1 Pragmatic  Func- 
tions - Prepare  prosel  constants  in  target  foianat. 

Pass  2 Optimizer  Constant  Arithmetic  Routine  - Modify 
constant  atithmetic  to  manipulate  target  form  values. 
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Most  of  these  modifications  are  individually  trivial;  however,  the  number  of  dif- 
ferent routines  to  be  examined  and  modified  makes  the  composite  task  moder- 
ately complex. 

A. 4.  3 NEW  DIRECT  CODE  PROCESSOR 

The  direct  code  processor  must  be  rewritten  for  each  new  target-machine  assem- 
bly language  format.  This  processor  is  a functionally  separate  module  which 
must  be  replaced  in  the  link- edit  of  the  first  analysis  phase.  This  necessitates 
target-machine  sensitivity  in  JXEC  to  load  the  proper  phase,  and  requires  the 
maintenance  of  a unique  analysis  Phase  1 for  each  target  supported  (all  but  the 
direct  code  processor  within  the  phase  have  the  same  code  for  each  target  machine). 

A. 4. 4 NEW  CODE  GENERATOR 

The  major  modification  for  retargeting  is  the  writing  of  a new  code  goneiotor. 

If  the  level  of  local  optimization  and  the  effective  realization  of  the  global  opti- 
mizations performed  by  the  optimizer  are  to  be  sustained,  a substantial  effort  is 
required. 

The  basic  architecture  of  the  current  mS-6000  code  generator  may  be  retained 
(which  considerably  reduces  the  design  effort),  and  much  of  the  machine- 
independent  code  (e.g. , the  triad  table  builder)  need  not  be  rewritten.  Still, 
this  must  be  considered  a major  task.  There  will  be  one  code  generator  for  each 
target  machine;  JXEC  will  select  the  appropriate  code  generator  phase. 

A. 4. 5 EDITOR  PHASE  MODIFICATION 

The  editor  phase  must  be  modified  (there  will  be  a unique  editor  for  each  sup- 
ported target)  to  generate  the  proper  assembly-like  object  code  listing.  The 
preset -constant  processing  also  must  be  modified  to  align  values  in  a manner 
consistent  with  the  target  machine  chai'acteristics. 
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A.  4.  6 OBJECT  MODULE  FORMATTER 


An  object  module  formatter  (actually  a part  of  the  editor  phase)  must  be  written 
for  each  target.  The  scope  of  this  task  is  a function  of  both  the  complexity  of  the 
object  module  format  requirements  and  the  reliability  and  clarity  of  the  system 
documentation  that  describes  it.  This  can  range  from  relatively  straightforward 
to  extremely  arduous. 

A. 4. 7 TRANSLATION  TO  TARGET  CONSTANT  FORMAT 

This  process  has  been  identified  in  preceding  paragraphs.  The  problem  is  to  con- 
vert from  the  compiler's  internal  constant  representation  to  the  target  machine 
format.  This  requirement  affects  several  compiler  modules.  For  example,  when 
the  optimizer  performs  compile  time  comparisons  between  character  constants, 
correct  inequalities  may  be  computed  only  when  using  the  target  representation, 
since  its  collating  sequence  may  not  be  the  same  as  the  host  character  representation. 

A. 5 SUMMARY 

JOCIT  is  best  described  as,  first,  a competent  and  serviceable  J-3  compiler  for  the 
HIS-6000  GCOS  machines  and,  second,  a J-3  compiler-building  tool.  The  advantages 
of  JOCIT  are: 

o Compiler  efficiency 

• Object  code  efficiency 
e Good  diagnostics 

• Excellent  debugging  facilities  (both  for  the  user  and  maintenance 
team) 

o Moderately  convenient  retargeting 

• Use  of  quick  bootstrapping  SYMPI.  compiler  tailored  to  .lOClT 
needs 
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The  disadvantages  are  the: 


r 


• Size  of  the  compiler 

• Changes  necessary  to  make  retargeting  even  less  costly 

• Changes  necessary  to  make  rehosting  less  costly  (a  moderately  - 
complex  task) 

• Reliance  on  a separate  SYMPL  compiler  that  does  not  take  advantage 


of  the  JOCIT  compiler’s  own  optimization  power  and  requires  separate 
(although  rare)  maintenance. 
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APPENDIX  B 

COMPILER  OPTIMIZATION  ENHANCEMENTS 

This  appendix  summarizes  enhancements  to  the  optimizations  presently  performed  which 
have  been  proposed  for  the  JOCIT  J-3  compiler.  It  serves  to  illustrate  the  general 
techniques  for  extended  global  optimization. 


:i 


The  optimization  scheme  now  employed  is  a Level-1  LNRA  (Linear  Nested  Region 
Analyzer)  scheme  implemented  as  a two-pass  process.  Pass  1 (known  as  OPTl) 
performs  all  flow  analysis  and  builds  tables  defining  set  and  used  information  for  each 
procedure  and  loop.  Pass  2 (known  as  OPT2)  performs  the  actual  transformations  to 
the  code  to  realize  the  principal  optimizations  of  common  expression  elimination, 
constant  arithmetic,  code  redistribution,  and  operator  strength  reduction.  The 
optimizer  phases  operate  on  the  IL  file  generated  by  the  analysis  phases  of  the  com- 
piler; all  transformations  are  expressed  in  the  IL,  and  the  output  is  also  in  the  form  of 
an  IL  file  which  is  subsequently  processed  by  the  code  generator  phase  (COGF2^).  This 
design  permits  selectable  optimization.  If  the  optimization  phases  are  by-passed  as 
they  are  when  the  NOPT  option  is  selected,  the  IL  generated  by  the  front  end  is  passed 
directly  to  the  code  generator.  In  this  mode,  only  those  local  optimizations  performc  d 
by  COGEN  are  effected,  and  no  global  optimization  is  performed  at  all. 

The  enhancements  discussed  in  this  appendix  assume  a solution  entirely  within  the 
framework  of  the  LNRA  design.  The  sum  of  these  improvements  will  be  to  raise 
the  level  of  generated  code  significantly.  It  is  expected  that  for  any  target  machine 
the  resultant  code  will  occupy  less  space  and  execute  in  less  time.  Furthermore, 
the  proposed  enhancements  do  not  violate  the  present  target-machinc-indcpendcnt 
design,  and  thus  the  tool  concept  is  not  compromised  in  any  way. 
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B.l  CODE  STRAIGHTENING 

In  the  LNRA  method  used  in  JOCIT,  program  flow  Is  determined  in  a single  forward 
scan  of  the  program  (performed  by  Optimizer  Pass  1,  or  OPTl).  It  is  the  assumption 
In  this  approach  that  a loop  is  formed  whenever  a label  is  reached  via  a backward 
branch.  Furthermore,  loop  optimization  is  suppressed  whenever  it  is  observed  that 
a forward  branch  enters  a loop;  i.e.,  redistribution  and  strength  reduction  are  not 
attempted  on  multiple-entry  loops  (because  of  the  complexity  of  placing  the  redistributed 
and  strength-reduced  initialization  computations  in  each  of  the  loop’s  entry  blocks). 
These  assumptions  are  entirely  valid  on  well-structured  or  "straight"  programs. 
However,  they  cause  the  optimizer  to  miss  some  cases  when  the  code  is  not  straight. 

A small  progfram  segment  demonstrates  this  pxsint. 

The  original  order  of  the  segment  consists  of  the  following  five  blocks  and  their 
Interconnecting  flow  paths: 


f 
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The  optimizer  sees  2-3-4  as  constituting  a loop  formed  by  the  backward  branch 
from  4 to  2.  However,  the  forward  branch  from  1 to  3 defeats  the  potential  loop 
optimization  as  described  above.  Earnest,  et  al.  (10)  have  proposed  an  algorithm 
that  may  be  applied  to  place  the  blocks  of  a program  in  the  straightest  possible  order. 

Its  application  of  the  preceding  example  produces  an  ordering  as  follows: 


This  reordered  segment  is  now  a single  entry  loop  (3-4-2),  and  redistribution  and 
strength  reduction  algoiithms  may  be  applied  to  Blocks  3 and  4.  Block  2,  which  is 
conditional,  is  excluded.  The  straightening,  then,  can  be  seen  to  have  improved 
the  optimization  potential. 

The  code  straightening  algoi'ithm  of  Earnest,  ct  al. , discovers  all  program  loops 
in  addition  to  straightening  the  order.  Asa  result,  the  code  stroightener  may 
be  used  to  replace  OPTl.  Instead  of  reading  the  IL,  the  straightener  will 
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read  an  extended  Global  Names  List  (GNL)  file,  which  will  be  called  the  Flow 
Graph  File  (FGF).  This  file  will  contain  each  program  label,  branch,  start 
PROC  and  end  PROC  delimiters,  PROC  call,  index  switch  label  list  and 
index  switch  call.  This  information  is  sufficient  to  identify  the  basic  blocks 
and  interconnecting  edges.  This  representation  will  then  be  reordered  by  the 
straightener,  and  the  resulting  straight  order  may  be  represented  by  an  ordered 
table  of  "hatchecks"  which  identify  the  blocks  of  the  IL  to  be  read  in  order  by 
OPT2.  The  FGF  will  be  enhanced  further  to  contain  entries  for  each  redefined 
variable — LHS  of  assignments,  actual  value  output  parameters,  and  name 
parameters — such  that  all  redefined  variable  lists  currently  produced  by  OPTl 
maybe  produced  by  the  straightener.  Since  the  FGF  is  considerably  smaller 
than  the  IL,  it  is  anticipated  that  the  straightener  will  be  significantly  faster 
than  the  present  OPTl. 

B.2  DEAD  VARIABLE  ANALYSIS 

A program  variable  is  said  to  be  dead  between  its  last  reference  and  a subsequent 
definition.  For  example,  in  the  program  sequence 

I ... 

QQ  F(I)$ 

• • • 

I ... 


the  variable  1 is  dead  between  the  assignment  to  QQ  and  redefinition  of  I in  the 
last  line.  Recognition  of  dead  variables  raises  two  optimization  possibilities 
which  should  be  examined  for  cost-effective  implementation;  (1)  store  suppiossion 
and  (2)  reuse  of  dead  variable  space. 
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In  the  above  example,  the  original  store  into  "I"  may  be  suppressed  if  it  is 
possible  to  retain  "I"  in  some  register  between  definitions.  Following  from 
this,  it  Is  seen  that  retaining  "I”  in  a register  means  that  no  storage  is 
required,  and  the  allocated  space  for  "I"  may  be  reused  during  the  program 
segment  where  "I"  is  "dead"  by  another  program  variable  or  compiler- 
generated temporary. 

Dead  variable  analysis  may  be  conveniently  performed  by  OPT2  after  an  entire 
region  has  been  processed.  An  extension  to  the  definition  of  a dead  variable 
may  Include  that  program  segment  between  a last  use  and  a progi’am  exit 
(or  PROC  RETURN).  However,  this  may  only  be  for  those  variables  whose 
first  reference  in  any  PROC  is  a redefinition  rather  than  a reference,  l.e. , 
those  whose  values  do  not  survive  from  one  invocation  of  the  PROC  to  the  next. 
Since  JOVIAL  does  not  pennit  the  programmer  to  distinguish  explicitly  between 
these  types  of  variables,  this  will  be  the  compiler's  task.  The  analysis  pro- 
cedure is  not  simple,  as  the  following  Uvo  procedures  demonstrate: 


PROC  A PROC  H 


I 


I 


X need  not  bo  materialized 
at  PROC'  exit 
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X must  be  materialized 
at  PROt'  exit 


In  PROC  A there  is  a path  (1-4-3)  on  which  "X”  is  used  before  it  is  set,  while 
In  PROC  B there  is  no  path  to  the  use  of  "X”  in  3 which  does  not  first  redefine 
"X". 

The  objectives  of  dead  variable  analysis  are: 

• To  suppress  unnecessary  stores 

• To  recognize  possibilities  of  allocated  space — sharing  between 
programmer  variables  and  compiler-generated  temporaries 

• To  eliminate  unnecessary  storage  allocation  for  variables  held 
in  registers 

® To  help  the  code  generator  retain  variables  in  registers 
B.3  LOOP  OPTIMIZATIONS 

In  addition  to  redistribution  and  strength  reduction  optimizations  currently  per- 
formed, loop  code  can  be  improved  in  the  following  areas: 

o Delaying  of  stores 

• Index  register  dedication  of  loop  control  variables  (including 
strength  reduction-generated  ones) 

o Register  dedication  of  redistributed  and  common  values 

o Strength  reduction  test  replacement  and  dead  loop  control  variable 
elimination 

• Strength  reduction  of  addition 
o Loop  collapse 

• Extension  of  sti'cngth  i-eduction  to  non-FOR  loops 
These  techniques  are  discussed  in  the  following  subsections. 
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B.3.1  DELAYING  STORES 

Often  with  loop  code,  a variable  is  repetitively  assigned.  All  but  the  store 
immediately  preceding  loop  exit  are  redundant,  and  dedicating  the  variable 
to  a register  within  the  loop  and  delaying  the  store  into  the  variable  until 
after  loop  termination  can  improve  loop  performance.  For  example,  in  the 
following  program: 

YY($0$)  = 0$ 

FOR  I = 1,1,99$ 

IF  XX($I$)  GR  YY($0$)$ 

YY{$0$)  = XX($I$)$ 

if  "YY''  is  dense-packed,  the  redundant  stores  within  the  loop  may  be  quite  costly, 
The  optimizer  may  recognize  the  case  and  ti'ansfonn  the  progi*am  as  follows: 

temp  = 0 $ 

FOR  I = 1,1,99$ 

IF  XX($I$)  GR  temp$ 
temp  = XX($I$)$ 

YY($0$)  = temp$ 

Thus,  in  the  example,  if  "temp"  is  dedicated  to  a register,  both  code  space  and 
execution  time  are  reduced. 

B.  3.2  INDEX  REGISTER-DEDICATION  OF  LOOP  VARIABLES 

Allocation  of  loop  control  variables  to  index  registers  eliminates  loads  and 
stores  within  the  bodj'  of  the  loop,  thus  compressing  the  loop  and  speeding  it 
up  as  well.  This  optimization  sliould  be  applied  both  to  progi-ammev  loop 
variables  and  to  optimizer-generated  loop  variables  arising  from  strength 
reduction . Such  dedication  may  be  expressed  by  means  of  accenting  the 


I 
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REPL  IL  operator  to  indicate  that  the  LHS  (the  loop  variable  initialization  and 
increment  code,  for  example)  is  a candidate  for  loop  dedication.  The  ENDL 
operator  would  signal  the  code  generator  to  free  such  loop-dedicated  vaiiables. 

B.  3. 3 REGISTER-DEDICATION  OF  REDISTRIBUTED  VALUES 

The  optimizer  moves  all  redistributed  values  into  the  loop  entry  block.  This 
redistribution  is  indicated  by  the  VALD  operator.  The  optimizer  will  mark 
such  redistributed  values  to  make  the  code  generator  aware  of  the  motion  and 
to  identify  the  loop  from  which  the  values  were  removed;  this  will  enable  the 
code  generator  intelligently  to  select  which  are  the  best  candidates  for  register 
dedication.  Even  on  limited  register  machines,  such  as  the  HTS-6000  series, 
this  can  be  useful  as  in  the  case  of  a table  search,  for  example: 

FOR  I = 0,1,999$ 

IF  XX($I$)  EQ  PATTERNS 
XX($I$)  = 0 $ 

In  this  case,  PATTERN  may  be  profitably  assigned  to  an  accumulator  before 
the  loop  (especially  helpful  if  XX  is  full-word  addressable),  and  the  interior 
of  the  loop  is  made  smaller  and  faster.  At  the  current  level  of  optimization, 
XX($I$)  is  loaded  and  compared  with  PATTERN,  whereas  (assuming  XX  is 
full-word  addressable)  PATTERN  may  be  loaded  outside  the  loop,  and  only 
the  com.parison  code  is  required  inside.  This  same  optimization  may  be 
performed  for  values  found  common  and  therefore  computed  outside  the  loop. 

B.4  STRENGTH  REDUCTION  TEST  REPLACEMENT  AND  DEAD  LOOP 
CONTROL  VARIABLE  ELIMINATION 

During  the  process  of  strength  reduction,  it  may  be  the  case  that  all  uses  of 
a loop  control  variable  \vill  have  been  reduced,  such  that  the  loop  control 
variable  may  be  considered  dead.  In  such  a case,  all  references  within  the 
body  of  the  loop  will  have  been  replaced  by  generated  loop  contixjl  variables. 
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and  the  code  to  initialize,  step,  and  test  the  original  variable  is  all  that  remains. 
Strength  reduction  tost  replacement  means  to  replace  the  test  of  the  original  loop 
control  variable  with  a derived  tost  on  a generated  loop  control  variable.  This 
can  be  seen  from  the  following  simple  example 

FOR  1 0,1,9$ 

XX($1*3$)  - 0 $ 

which  when  reduced  in  strength  by  the  optimizer  effectively  becomes; 

temp  = 0 $ 

FOR  I = 0,1,9$ 

BEGIN  "1" 

XX($temp$)  0 $ 
temp  = temp ' 3$ 

END  "I" 

If  the  tost  against  I were  replaced  by  a test  against  temp,  the  pn>gram  could  be 
written: 

FOR  temp  0,3,27$ 

FORI  0,1$ 

XX($tomp$)  0 $ 

Thus,  the  use  of  1 is  entii'ely  dead,  all  i-eferenccs  arc  eliminated,  and  tlie  following 
simplifieii  and  improved  progi'am  emei*gcs: 

FOR  temp  0,3,27$ 

XX($temi>$)  0 $ 

B.4.1  S111ENGT1I  REDDGTION  OF  ADDITION 

The  current  strength  reduction  algorithm  incliules  only  the  ix'duction  of  multi- 
plication and  exi)onentiation.  The  reciuclion  of  addition  (which  rediu  os  to 


another  addition)  is  sensible  when  it  leads  to  further  reduction  possibilities. 

For  example,  the  following  program, 

FOR  I = 0,1,99$ 

BEGIN  "1" 

FOR  J = 0,1,99$ 

AA($I,J$)  0 $ 

END  "I" 

in  the  current  JOCIT  model  reduces  only  the  implicit  multiply  of  J;  the  subscript 
expression  (1.  -D  Is  linearized  to  (I+d^  ♦J),  where  dj  is  the  first  dimension  of  AA. 
Assuming  that  AA  is  100  by  100  (d^  is  then  100)  the  equivalent  code  after  strength 
reduction  is: 

FOR  I 0,1,99$ 

BEGIN  "I" 

t^  = 0 $ "REDUCTION  OF  lOOM  WlflCIi  IS  INITIALLY  0" 

FOR  J = 0,1,99$ 

BEGIN  "J" 

AA($1  t^$)  - 0 $ 

= t J 4100$ 

END  "J" 

END  "1" 

An  improvement  to  this  would  result  fi*om  the  i-oduction  of  the  In  the  inner 
loop.  A straightforward  I'cduction  would  give; 


I 


t 
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FOR  I = 0, 1 , 99$ 

BEGIN  "I" 

tj  = 0$ 

t = 1$  "FROM  REDUCTION  OF  I ‘t  WHICH  IS 
^ INITIALLY  I" 

FOR  J = 0,1,99$ 

BEGIN  "J" 

AA($t2$)  = 0 $ 

^100$ 

=^12^100$ 

END  "J" 

END  "I" 

This  reduction  as  shown  Is  actually  a degradation  of  the  original  program  unless 
the  dead  loop  control  analysis  is  applied  along  with  test  roplacement.  The  result 
is  a significant  improvement  as  the  following  equiv'alent  progi’am  shows. 

FOR  I = 0,1,99$ 

BEGIN  "I" 

FOR  t - 1,100, 9900 
AA($t2$)  - 0 $ 

NOTE;  The  expression  9900*1  is  loop  constant  over  the  inner  loop,  and  thus 
is  properly  redistributed. 

B.4.2  LOOP  COLLAPSE 

If  the  preceding  example  were  rewritten  with  the  subsci'ipts  iwerseii, 

FORI  0,1,99$ 

BEGIN  "I" 

FOR  J 0,1,99$ 

AA($J,1$)  0$  "J,l  instead  of  I,. 1" 

END  "I" 
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the  effective  reduction  looks  like  the  following: 


tg  = 99$ 

FOR  t j = 0,100,9900$ 

BEGIN  "tj" 

FORt2  = t^,l,tg$ 

AA($t2$)  = 0 $ 

t3  = tg  + l00$ 

END  "t^" 

A close  analysis  of  the  above  reduction  reveals  that  the  inner  loop  control 
variable  (the  generated  one,  t ) steps  consecutively  from  0 to  9999;  thus,  the 
inner  loop  may  be  collapsed  into  the  outer  loop  leaving  a single  loop  as  follows; 

FOR  t^  = 0,1,9999$ 

4 

AA($t^$)  = 0$ 

This  continuous  stepping  function  may  be  recognized  by  observing  that  the 
difference  between  the  terminal  value  of  one  itei-ation  and  the  initial  value  of 
the  next  is  precisely  the  step  value  of  the  inner  loop  control.  For  example, 
the  terminal  value  of  Mie  t ^ on  the  first  iteration  is  99  (t  g),  and  the  initial 
value  of  the  second  iteration  is  100  (stcpixjd  value  of  t ^1;  the  difference,  1, 
is  the  step  value  for  t^. 

A comparison  of  the  various  levels  of  optimization  discussed  as  applied  to  the 
simple  example  discussed  above  shows  the  progressive  impnn'ements.  The 
examples  shown  use  the  HIS-GOOO  insti'uction  set. 
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Optimization 


Total:  14/lnner  loop:  8 (inch  multiply) 
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Optimization  - l.evel  2;  Reduction  of  Addittoa.  Test  Replncemcnt, 
Dead  Loop  Variable  Elimination 

Total:  15/lnner  Loop:  6 
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B.4.3  EXTENSION  OF  STRENGTH  REDUCTION  TO  NON-FOR  LOOPS 


In  the  current  JOCIT  optimizer,  strength  reduction  is  applied  only  to  formal 
(i.e. , FOR)  loops.  Strength  reduction  may,  however,  be  generalized  to  include 
the  reduction  of  functions  of  any  variable  satisfying  the  following  conditions: 

o The  variable  is  iterativdy  redefined  once  only  with  the 
scope  of  some  loop;  i.e. , the  variable  C'l"  for  example) 

Is  defined  by  I = Dk  or  I = I-k 

o The  variable  is  nowhere  else  redefined  within  the  loop 

o The  redefinition  expression  (k  in  the  above  example)  is 

constant  over  the  same  loop  in  which  the  variable  is  iteratively 
redefined 

The  recognition  of  such  variables,  functions  of  which  are  candidates  for  reduction, 
will  be  the  responsibility  of  OPT2  which  will  employ  a double  scan  program  loops 
Identified  by  OPTl. 

B.5  PARALLEL  PATH  OPTimZATIONS 

The  IF. . .THEN. . . ELSE  and  CASE  constructions  in  HOLs  produce  parallel  paths 
in  the  resulting  program  flow  graph.  Certain  optimization  possibilities  arise 
because  of  this  form  of  flow  which  are  not  addressed  in  the  present  JOCIT  optimizer. 
The  optimizations  considered  in  the  following  sections  are; 

o im  proved  forward  flow  analysis 
o Load  promotion/store  delay 
o Common  name  recognition 
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B.6  IMPROVED  FORWARD  FLOW  ANALYSIS 

In  the  current  JOCIT  optimizer,  all  forward  branches  are  treated  as  conditional 
insofar  as  their  effect  on  the  state  of  the  search  set  is  concerned.  For  example, 
in  the  following  program  segment: 


the  assignment  to  "a"  in  Block  2 prevents  "a^b"  in  Block  3 from  being  recog- 
nized as  common  with  that  in  Block  1 although  they  compute  the  same  value. 
The  analysis  can  be  improved  in  OPT2  by  restoring  search  set  value  numbers 
at  block  entrances  whose  immediate  textual  predecessor  block  exits  by  an 
unconditional  branch. 

B.6.1  LOAD  PROMOTION/STORE  DELAY 

In  any  multipath  graph,  code  space  can  be  saved  by  preloading  common  values 
and  by  delaying  common  stores  as  the  following  simple  case  demonstrates: 

IFEITH  BOOL$ 

AA($IiJ$)  = KK*5$ 

ORIF  1 $ 

AA($LJ$)  - KK*5a$ 
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In  the  current  JOCIT  compiler,  if  neither  I t^J  nor  KK*5  appear  before  the  IFEITH 
the  code  (shown  for  the  HIS- 6000)  will  be: 


LDA 

BOOL 

TZE 

Ll 

LDQ 

I 

ADQ 

J 

EAXO 

0,QL 

LDQ 

KK 

MPY 

5,DL 

STQ 

AA,X0 

TRA 

L2 

Ll 

LDQ 

I 

ADQ 

J 

EAXO 

0,QL 

LDQ 

KK 

MPY 

5,DL 

ADQ 

1,DL 

STQ 

AA,X0 

L2 

• • « 

Total 

16 

Applying  the  diamond  optimizations, 

the  code  would  be; 

LDQ 

I 

ADQ 

J 

PRECOMPUTE  I ‘ J 

EAXO 

0,QL 

SAVE  IN  XO 

LDQ 

KK 

MPY 

5,DL 

PRECOMPUTE  KK*5 
SAVE  IN  Q 

LDA 

BOOL 

TNZ 

L2 

TRUE  CASE  NOW  NULL: 

Ll 

ADQ 

1,DL 

FALSE  CASE: 

COMPUTE  KK*5  1 

L2 

STQ 

AA,X0 

DELAYED  STORE  OF 
AA($I'J$) 

Total 

9 
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Reduction  44% 
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b.7  name  commonality 

The  current  JOCIT  optimizer  employs  the  value-folding  technique  to  implement 
common  expression  recognition.  This  excludes  recognition  of  certain  cases  in 
which  expressions  are  computed  on  parallel  paths  which  are  formally  common 
but  which  may  compute  different  values.  The  following  program  example 


demonstrates: 

IFEITH  BOOL$ 

pp(xx+yY)$ 

ORIF  1$  BEGIN 

XX=XX-1$  PP(XX-YY)$ 

END 

...XX^YY... 

In  this  example,  the  expression  XX- YY  after  the  IFEITH/ORIF  construction 
is  formally  common  with  the  XX- YY  computed  on  each  path  of  the  diamond; 
however,  since  it  computes  different  values — XX  is  redefined  on  the  ORIF 

path the  optimizer  will  not  recognize  the  common  case.  This  problem  may 

be  solved  within  the  present  value-folding  design  by  the  following  technique: 

• At  the  terminus  of  parallel  paths,  all  live  names  and  expressions 
are  permuted  for  formal  name  matching.  This  involves  examining 
the  value  synonym  list  and  substituting  the  different  name  synonyms 
until  the  list  is  exhausted  or  a match  occurs  on  both  paths.  In 
practice,  synonym  lists  for  values  are  quite  short,  so  that  this 
process  is  not  prohibitively  slow. 

e Common  names  and  expressions  so  recognized  are  then  assigned  to 
temps  on  the  parallel  paths,  (e.  g. , XX  YY  is  assigned  to  T1  on 
both  paths  in  the  above  example).  The  same  temp  is  used  as  a 
surrogate  name  for  the  common  expression.  This  is  to  give  the 
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expression,  on  both  paths,  a common  residence  which  the  code  genera- 
tor may  subsequently  assign  to  a register  in  order  to  achieve  the 
desired  optimal  effect. 

• Common  names  and  expressions  thus  recognized  are  now  posted  to 
the  search  set  in  the  usual  manner,  and  the  temp  is  also  posted  as 
a synonym  for  the  posted  value.  Thus,  subsequent  occurrences  of 
the  expression  are  found  common  through  the  conventional  folding 
technique.  Dead  variable  analysis  may  delete  the  assignments  to 
the  temps  on  the  parallel  paths.  The  optimization  is  realized  by 
the  code  generator  when  it  is  called  to  compute  the  value  common 
subsequent  to  the  parallel  network;  the  temp  (which  may  have  been 
register-dedicated  on  each  path)  is  chosen  as  the  optimal  source  of 
the  value. 

In  the  example  given  above,  the  value  XX^YY  is  stored  in  a temp,  the  same 
temp,  on  each  path  in  order  for  it  to  be  passed  as  a value  parameter  in  the 
calls  to  PP.  Thus,  references  to  XX  YY  after  the  diamond  may  be  replaced 
by  references  to  ihe  temp. 

B.8  USE  OF  COMPOOL  BY  THE  OPTIMIZER 

B.8.1  REDEFINED  VARIABLE  LISTS  FOR  COMPOOL  DEFINED  PROCEDURE 

Optimization  may  be  enhanced  through  extension  of  tlie  COMPOOL  concept. 

The  greatest  potential  payoff  is  in  refining  the  spoil  analysis  at  COMPOOL- 
defined  procedure  calls.  Another  useful  application  is  in  the  use  of  brancdi 
frequency  information  to  improve  certain  loop  optimizations. 

In  the  present  JOCIT  optimizer,  calls  to  local  procedures  invoke  a spoiling 
process  in  which  only  those  variables  global  to  the  called  procedure  and  also 
to  the  point  of  call  are  assumed  to  bo  redefined  by  the  call.  This  process 
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is  mechanized  In  OPTl  which  constructs  a list  of  global  variables  redefined  by 
the  procedure.  The  list  also  includes  other  procedures  called,  so  that  cascaded 
effects  are  accommodated.  For  calls  to  externally-defined  or  COMPOOL- 
defined  procedures,  the  optimizer  makes  the  assumption  that  all  external  and 
common  data  are  spoiled  by  the  call.  This  is  clearly  a safe  but  overly  conser- 
vative assumption. 

An  improvement  may  be  experienced  by  appending  redefined  variable  list  informa- 
tion to  the  COMPOOL  entry  for  each  procedure  during  COMPOOL  assembly.  This 
requires  one  or  both  of  two  other  changes  to  the  COMPOOL  process.  The  first 
requires  the  programmer  to  specify  in  the  COMPOOL  declaration  for  the  pro- 
cedure those  global  variables  assigned  and  those  external  procedures  called. 

The  second  approach  requires  that  the  COMPOOL  source  for  procedures  include 
the  entire  procedure  body.  In  this  case,  OPTl  would  be  called  as  part  of  the 
COMPOOL  assembly,  and  its  constructed  RVL  would  be  output  with  the  procedure 
entry  in  the  COMPOOL. 

B.8.2  BRANCH  FREQUENCY  DATA 

As  part  of  the  integrated  approach  to  the  LCF  design,  execution  measurement 
data  may  be  subjected  to  postmortem  reduction  and  the  branch  frequency  data 
entered  into  the  program  COMPOOL.  The  branch  points  would  be  identified  by 
statement  number.  Thus,  subsequent  compilations  of  the  program  would  pro- 
vide for  access  to  the  branch  frequency  data  in  that  program's  COMPOOL  by 
the  optimizer  for  the  purposes  of  replacing  branch  frequency  assumptions  by 
actual  operational  experience.  A limitation  inherent  in  this  approach  is  that 
source  program  modifications  to  the  measured  program  are  prohibited  between 
any  measured  execution  and  a subsequent  recompilation.  This  guarantees  that 
the  statement  number  data  is  consistent  between  the  COMPOOI.  and  the  sul>- 
sequent  compilation. 
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B.9  MISCELLANEOUS  OPTIMIZATION  ENHANCEMENTS 


B.9,1  VALUE  USAGE  CONTEXT 

The  optimizer  will  set  bits  In  each  VALU  entry  in  the  IL  to  Indicate  the  con- 
texts In  which  the  value  Is  used.  These  bits  may  distinguish  between  computa- 
tional usage  and  subscript  usage,  for  example,  and  will  aid  the  code  generator 
In  register  allocation  for  values.  For  example,  a value  having  only  subscript 
uses  may  be  profitably  allocated  to  an  Index  register.  The  current  JOCIT  code 
generator  already  makes  use  of  this  Information,  so  the  setting  of  these  bits 
yields  a low-cost  object  code  efficiency  improvement. 

B.9.  2 UNREFERENCED  PROCEDURE  DELETION 

It  frequently  happens  that  as  a program  ages,  certain  procedures  are  no  longer 
referenced,  and  the  programmer  falls  to  remove  them.  This  is  an  easy  case 
for  the  compiler  to  recognize,  and  the  unreferenced  procedure  need  not  be 
compiled. 

B.9. 3 SINGLE-REFERENCE  PROCEDURE  OPTIMIZATION 

A procedure  with  only  one  reference  may  perhaps  be  more  efficiently  compiled 
as  an  open  routine  with  actual  parameters  substituted  for  formal  parameters. 
This  substitution  may  be  performed  by  OPT2  (or  perhaps  the  straightcnerl  by 
collecting  the  actual  parameter  IL  code  and  substituting  it  for  the  corresponding 
tormal  parameter  IL  code,  and  by  eliminating  the  procedure  pix>loguo  and 
epilogue. 

B.9.4  REFINED  REGION  DEFINITION 

That  segment  of  the  program  optimized  by  the  JOCIT  compiler  in  a single  unit 
is  known  as  a region.  Currently  it  is  the  case  that  a xvgion  break  occurs  when 
the  optimizer  exhausts  working  storage  for  the  region.  Wlicn  this  ijapjH'ns,  the 
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IL  is  flushed,  and  working  space  is  recovered  for  the  next  region.  In  the  pro- 
duction compiler,  working  space  is  sufficient  to  permit  the  optimization  of 
several  hundred  source  lines  per  region. 

It  is  suggested  that  the  region  end  definition  be  refined  to  prevent  the  termination 
of  a region  within  a loop  that  might  otherwise  be  contained.  This  can  be  accom- 
plished by  the  straightener,  which  will  record  for  each  loop  entry  in  the  loop  list 
the  number  of  IL  entries  associated  with  the  loop  body.  OPT2  may  then  estimate 
the  working  storage  requirements  - based  on  the  IL  count  for  the  loop  - whenever 
a loop  top  is  seen  and  terminate  the  region  before  the  loop  in  the  event  that 
working  space  is  insufficient.  This  will  permit  the  optimization  of  a loop,  or 
next  of  loops,  within  a single  region,  which  the  termination  of  a region  in  mid- 
loop prevents  (e.g. , after  such  a region  end,  no  strength  reduction  or  redistribu- 
tion may  occur). 

B.9.5  REASSOCIATION,  DISTRIBUTION,  AND  CONSTANT  COLLECTION 

Subscript  expressions,  linearized  by  the  analysis  phase,  may  be  more  com- 
pletely optimized  if  the  rules  of  reassociation,  multiply  distribution,  and 
constant  reordering  are  applied.  These  rules,  to  be  implemented  in  OPT2, 
are  summarized  as  follows  ("K"  stands  for  any  constant,  and  stands  for 
any  associative  operator*): 

Reassociation 

1.  The  expression  (A  & Kj^)  & K2  is  changed  to  A & Kg, 
where  Kg  - Kj  & K2 

2.  The  expression  (A  & K)  & B is  changed  to  (A  & B)  & K 

3.  The  expression  (A  & Kj)  & (B  & K2)  is  changed  to  (A  & B)  & Kg, 
where  Kg  Kj  & K2 


♦Add  and  multiply  are  the  only  associative  operators  of  interest  in  this  discussion. 
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Distribution  of  Multiply 

4.  The  expression  (A  * Kj)  * K2  Is  changed  to  (A  ♦ K2)  ' K3, 
whore  Kg  Kg  * Kj 

Constant  Reordering 

5.  The  expression  (K  & A)  Is  canonically  reordered  to  (A  & K) 

The  effect  of  these  can  be  seen  on  the  following  two-dimensional  array  refer- 
ence XX  ($1  where  XX  is  a lO-by-10  array.  The  linearized  subscript 

is  (1  •!)  ‘ (J  '2)'*10.  The  successive  application  of  the  above  rules  to  the  triads 
as  seen  left-to-rlght  Is  shown: 

(1  ‘1)  becomes  0 ‘1)  l^y  Rule  5. 

(J  t2)*10  becomes  (J*10)  '20  by  Rule  -1. 

(I4l)(  (J  + 10) ‘20)  becomes  (I-*  (-1^1 01) '21  by  Rule  .1. 

One  of  the  primary  effects  of  these  i-ules  Is  that  any  constant  offset  is  floated 
to  the  right  where  it  is  ivmove<l  by  the  code  generator  and  placed  In  the  address 
field  as  an  addtvss  offset. 
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